related: #K8SOP-246

What

Overhauls RBAC across all three operator deployments (api-manager, agent-manager, bindings-forwarder) to:

1. Hand-manage all RBAC in Helm templates — removes controller-gen RBAC generation and all 73 kubebuilder:rbac markers from Go code. This follows the pattern used by cert-manager, Kyverno, ArgoCD, and other multi-deployment operators.
2. Reorganize into per-component directories — each deployment's templates (deployment, SA, RBAC) live in their own directory (api-manager/, agent/, bindings-forwarder/).
3. Add namespace-scoping support — when watchNamespace is set, namespace-scoped resources use a Role instead of a ClusterRole. Cluster-scoped resources (namespaces, ingressclasses, gatewayclasses) remain in a ClusterRole.
4. Fix all known RBAC bugs (see below).

How

Bug fixes

• Delete 4 stale CRD access roles referencing non-existent CRDs (bindingconfiguration, operatorconfiguration)
• Fix boundendpoint editor/viewer roles — wrong API group (ngrok.k8s.ngrok.com → bindings.k8s.ngrok.com)
• Remove dead proxy-role ClusterRole (leftover kube-rbac-proxy scaffolding)
• Fold secret-manager-role into api-manager role (add secret create/update/patch)
• Remove stale tunnels rules from agent ClusterRole (Tunnel CRD no longer exists)
• Remove duplicate events rule from bindings-forwarder
• Remove misapplied clusterRole.annotations from operator-internal roles

Restructure

• Move controller-*.yaml templates into templates/api-manager/ directory
• Split monolithic RBAC files into per-resource files (role.yaml, rolebinding.yaml, etc.)
• Rename service-account.yaml → serviceaccount.yaml for consistency
• Move CRD access roles into templates/rbac/crd-access/ with consistent naming
• Add missing CRD access roles for AgentEndpoint, KubernetesOperator, NgrokTrafficPolicy

Go / build changes

• Remove all 73 +kubebuilder:rbac markers from 18 Go files (comment-only changes)
• Remove rbac:roleName=... and output:rbac:... from controller-gen command in generate.mk

values.yaml

• Rename clusterRole → crdAccessRoles (only applies to CRD access editor/viewer roles)
• Add crdAccessRoles.create toggle

Namespace-scoping

• New isNamespaced and watchNamespace helpers in _helpers.tpl
• Each component gets role.yaml (ClusterRole, default) and role-namespaced.yaml (Role, watchNamespace) with simple if/if not guards
• api-manager splits into: Role (namespace-scoped resources) + ClusterRole (cluster-scoped resources) in watchNamespace mode

Verification

• RBAC baseline captured from kind cluster before refactor (specs/rbac/)
• After refactor: redeployed, diffed kubectl auth can-i --list per SA against baseline
• All intentional diffs documented in design doc

Used a script to dump permissions for all our service accounts across the namespaces default, ngrok-operator where its installed, and test-ns-to-watch which would be sometimes used for watchNamespace. Then used diff to see

• main vs main-watchNamespace has no diffs as expected
• main vs branch
  • config maps got patch. while not needed technically, they had update, so this is just a consistency thing
  • removed cluster scoped k8soperator crd access as it only needs it in its own namespace. it still has access in the ngrok-operator namespace though
  • removed old things that aren't used that were skaffolded by kubebuilder like subjectaccessReview and tokenreview
  • secrets got delete access removed as i couldn't find where we used it and seemed worth limiting the scope
• for branch vs branch-watchNamespace there are lots of diffs removing all the crd access from the individual namespaces but remain in the test ns to watch. bindings is also unaffected

Breaking Changes

• clusterRole.annotations renamed to crdAccessRoles.annotations in values.yaml. Users setting this value will need to update their Helm values.
• proxy-role ClusterRole removed (grants tokenreviews and subjectaccessreviews). This was dead scaffolding from kube-rbac-proxy which was never deployed. No functional impact.
• Bindings-forwarder pods ClusterRole removed — pods access moved to the namespaced Role. Only affects users who relied on the forwarder reading pods across namespaces (it doesn't — it only watches pods in its own namespace).